The structured query language (SQL) can be in the form of standalone (individual) SQL statements, part of database procedure (e.g., stored procedure), or embedded (i.e., contained), dynamic or static, in any high-level programming language (for example: C/C++, JAVA, COBOL, and ABAP). These SQL statements, standalone, part of database procedure, or embedded, can be very complex and may contain, for example, hundreds of lines of code including complex joins of multiple database tables/views, multiple sub (nested)-queries, and/or filters. Without the ability to debug such SQL statements it is very hard to develop and maintain them and the result is a poor user experience, and/or introduces errors that can result in a higher total cost of ownership for users. Database procedure debuggers typically support debugging (e.g., detection and correction) of a database procedure's logic portion but treats the SQL statement (natural dominant database procedure part) as an atomic step (e.g., a black box) without a step-in capability—i.e., where a user can view a final result of the SQL statement but without understanding a result of each an ordered set of sub-steps (intermediate results) associated with the SQL statement which are used to access or modify information. As a database procedure body can include very complex SQL statements, a typical database procedure debugger can be useless as the logic surrounding the included SQL statements might be relatively simple compared to the SQL statements themselves or even possess no logic at all. Without the ability to debug the included SQL statements, also database procedures can be difficult to debug. This SQL debug becomes an even more critical problem today due to the growing trend of massive database usage in business applications.